1. Field of the Invention
Embodiments of the present invention generally relate to a method for regaining memory consistency after a trap using transactional memory and a transactional memory log.
2. Description of the Related Art
Concurrent computing generally refers to the simultaneous execution of multiple tasks, usually on a multiprocessor system. These tasks are often implemented by a set of threads (short for “thread of execution”) contained by a process (an executing computer program). The threads of a particular process often access the same data structures in memory. Allowing multiple threads to access the same data structures may lead to consistency problems and locking techniques are often used to prevent threads from interfering with each other and corrupting memory. For example, if a first thread is modifying a particular data structure in memory, then the data structure may be “locked” to prevent a second thread from accessing or modifying the data structure until the lock is released. Locking, however, is particularly pessimistic. That is, the data structure remains locked to the second thread regardless of whether concurrent access by both threads would lead to an inconsistency.
Further, a locking mechanism may not prevent certain particular types of consistency errors. For example, consider a thread configured to add an element to a doubly linked list. Typically, such a thread would perform the following steps (set forth in a pseudo code format):
Add_element { newNode->previous = node; newNode->next = node->next; node->next->previous = newNode; node->next = newNode; }The first two lines insert the newNode element following the node element and set pointers for the newNode element to the appropriate previous and subsequent elements in the list. The third and fourth line adjusts pointers in the previous and next elements in the list to point to the newNode element. Because concurrent access to these elements could lead could lead to inconsistent results, a locking mechanism may be used to protect the list while the Add_element routine is performed.
However, if a trap event occurred part way through these steps, a locking mechanism might not prevent the list from being left in an inconsistent state. For example, consider the following sequence of program flow:                1. Lock the doubly linked list.        2. Invoke the Add_element routine to add a new element        3. Part way through the Add_element routine, a trap event occurs causing program control to jump to a known jump point previously set for the trap event.        4. Unlock (not reached).In this example, the thread stack is correct, and further processing could occur. However, this sequence leaves the linked list in an inconsistent state and locked. There is no effective mechanism to unlock the list and undo the partial update to the linked list that occurred prior to the trap event. Thus, in cases such as this, unpredictable results may occur depending on how the doubly linked list is parsed, or the application may simply terminate if an application thread subsequently attempted to dereference an uninitialized node pointer.        